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The invention relates to the provision of services at a service gateway that connects an 
external network (e.g., the Internet) to an internal network. A service gateway provides 
5 services for local clients for supporting local client systems and devices. A service 
gateway can be implemented in a network connected computer system or server 
computer, a router, a set-top box, a power supply meter, or the like. 

The local clients can include a number of devices connected within a local environment. 

10 The local environment might, for example, be the home, a workspace, a factory, a farm, 
a vehicle, or the like. As technology develops, those devices are more and more likely to 
be supported by a service provider via network links. In order to provide the support, 
there can be a need to provide software modules, programs, data, etc. to the local, or 
home environment. This can be addressed by providing the software modules, 

15 programs, data etc. at a service gateway providing an interface between the local 
environment and the external network. 

A difficulty with this is that different configurations and needs will exist at different 
client sites. Typically different combinations of equipment will exist at those sites, 
20 Also, the configurations and needs will change with time, for example as new versions 
of software modules come into existence, in order to provide diagnostic fiinctions in 
response to faults, and as the devices and other systems at the client site change. 

In view of this, there is a need to be able to respond to requests that can come from the 
25 service provider side, or from the client side, for the provision of new services at the 

service gateway. The challenge is therefore to provide a mechanism that can enable the 
loading of services into the service gateway. However, at present, the development of 
such systems is hampered because developers do not have mechanisms that allow them 
readily to expand and change the way that services are provided via a service gateway. 
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The present invention seeks to address this. 
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Particular and preferred aspects of the invention are set out in the accompanying 
independent and dependent claims. Combinations of features from the dependent claims 
5 may be combined with features of the independent claims as appropriate and not merely 
as explicitly set out in the claims. 

In one aspect, the invention provides a service gateway for connecting at least one local 
client to an external network. The service gateway is operable to hold at least one 

10 service module for providing a corresponding service. The service gateway includes a 
control mechanism that is operable in response to a request for a service provided by a 
service module not present at the service gateway, to send a message to an external 
source for resolving the absence of a service module at the gateway. The control 
mechanism is operable to send messages to an external source in one or more iterations 

15 until a response from the external service identifies information including a service 
module held by the gateway that enables resolution of the absence of the service 
modules(s). 

The service gateway is thus arranged to provide an iterative or recursive process for 
20 repeatedly seeking a farther service until the necessary software and/or data is available 
at the service gateway to satisfy the original service request. 

The service gateway can be operable to hold at least one service module for providing a 
corresponding service and to maintain a record identifying each service module held by 
25 the service gateway with an associated pointer to that service module. 

The control mechanism can, for example, operate in the following manner. The control 
mechanism can react to a request identifying a first service module by accessing the 
record to identify whether the first service module is held by the service gateway. If the 
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first service module is held by the service gateway, it uses the associated pointer to cause 
the first service module to provide the corresponding service. If the first service module 
is not held by the service gateway, it makes a request for the first service module to an 
external source by sending a message to the external source including the identity of the 
5 first service module. The control mechanism further reacts to a response from the 

external source identifying a second service module by accessing the record to identify if 
the second service module is held by the service gateway. If the second service module 
is held by the service gateway, it uses the associated pointer to cause the second service 
module to provide the corresponding service. If the second service module is not held 
10 by the service gateway, it requests support from an external source by sending a message 
to the external source including the identity of the second service module. 

The control mechanism can be further operable to react to a response from the external 
source identifying a further service module by accessing the record to identify if the 

15 further service module is held by the service gateway. If the further service module is 
held by the service gateway, it uses the associated pointer to cause the farther service 
module to provide the corresponding service. If the further service module is not held by 
the service gateway, it requests support from an external source by sending a message to 
the external source including the identity of the further service module. It can thus be 

20 seen that this process can be operable iteratively until a further service is indeed 
provided by the service gateway. 

The control mechanism can be operable to compare successive responses from an 
external source to identify response duplication indicative of a recursive error. This can 
25 be checked, for example, by tracking the service names that are looked up in the record 
of services. 

The control mechanism can be configured to react to the identification of a service 
module and associated data in a response from an external source to supply the data to 
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the identified service module, if held by the service gateway, for processing by the 
service module. 

The external source can be a service provider for providing services to the local client. 
5 Alternatively, it can be a service gateway operator that provides functionality to the 
service gateway. 

Another aspect of the invention provides a computer program comprising computer code 
operable in a service gateway computer for connecting at least one local client to an 
10 external network, the program code being operable to provide the fimctionality of the 
control mechanism described above. 

A computer program can include a carrier medium to carry the computer code. The 
carrier medium can be a storage medium or a transmission meditim, for example. 

15 

A further aspect of the invention provides a service gateway system comprising a 
processor and memory, the system being configured to provide a service gateway as set 
out above. For example, the system can include a computer program as defined above. 

20 Another aspect of the invention provides a method of connecting at least one local client 
to an external network via a service gateway. The method includes a step of holding at 
least one service module in the service gateway for providing a corresponding service. 
In response to a request for a service provided by a service module not present at the 
service gateway, at least one message is sent in at least one iteration to an external source 

25 for resolving the absence of a service module at the gateway until a response from the 
external service identifies information including a service module held by the gateway 
that enables resolution of the absent service modules(s). 
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An embodiment of the invention thus provides an iterative process for obtaining support 
for a client served by the service gateway, whereby it is possible to update the services 
provided by the service gateway in a flexible and extensible manner. 
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Exemplary embodiments of the present invention will be described hereinafter, by way 
of example only, with reference to the accompanying drawings in which like reference 
5 signs relate to like elements and in which: 

Figure 1 is a schematic overview of a network environment including a service gateway; 
Figure 2 is a schematic representation of an example of a service gateway system in the 
form of a set-top box; 

10 Figure 3 is an overview of an exemplary hardware configuration of components of the 
service gateway; 

Figure 4 is a schematic block diagram of a software environment of a services service 
gateway; 

Figure 5 is a schematic block diagram of a software components of the services service 
15 gateway; 

Figure 6 illustrates a number of stages in an example of operation of an embodiment of 
the invention; and 

Figure 7 is a flow diagram illustrating an example of operation of an embodiment of a 
service gateway according to the invention. 
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DESCRIPTION OF PARTICULAR EMBODIMENTS 

Exemplary embodiments of the present invention are described in the following with 
reference to the accompanying drawings. 

5 

Figure 1 is a schematic representation of an implementation of an exemplary 
embodiment of the invention. 

Figure 1 shows an external network environment (for example the Internet) 1 0 to which 
10 a number of stations are connected. As shown in Figure 1, a service gateway station 12 
is connected to the Internet 10 via a connection 14 and provides an interface to a local, or 
home, environment 20. The service gateway station 12 as shown in Figure 1 supports 
two local networks in the local environment 20. The service gateway station 12 is 
connected to the first local network 20 via a connection 16 and to a second local network 
15 24 via a connection 1 8. In each case, a number of devices are connected to the local 
networks 22 and 24. The provision of two local networks is merely an example, for 
illustrative purposes. One or more local networks may be provided. Each of the local 
networks may support the same or different local protocols for servicing individual 
devices 26 connected to the local network(s) 22/24. 

20 

In a particular example to which the present embodiment relates, the local environment 
is a domestic environment in the home where a number of domestic devices are 
connected or connectable to the network. The devices may include complex systems 
such as computer systems, audio visual equipment, etc, domestic control systems such as 
25 security systems, environmental control systems, etc, and all manner of devices which 
previously have not been network enabled such as white goods (e.g., refrigerators, ovens 
and other kitchen equipment), and so on. 
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In other examples the local environment can include one or more of the following, 
namely a workplace, an office, a factory, a farm^ a vehicle, an exhibition site, etc. 

A service gateway operator station 28 is connected to the Internet 1 0 via a connection 
5 30, and is optionally connected directly to the service gateway by a further connection 
(for example a telephone connection) shown as a dotted line 3 1 . The service gateway 
operator station 28 is typically operated by a service gateway operator that provides 
information for control of the service gateway station 12 and provides services (for 
example as program modules) for defining the functionality of the service gateway 
10 station 12. 

Two service provider stations 32 and 36 are also connected to the Internet 10 by 
respective cormections 34 and 38. The service provider stations can typically be 
operated by providers of services relating to the individual devices 26 within the local 
environment. For example, one service provider can be a manufacturer of audio/visual 
devices 26 within the local environment and can provide services for supporting those 
devices. Another service provider can be a manufacturer of white goods forming 
devices 26 within the local environment 20 and can provide services for supporting those 
white goods. Examples of possible services are remote diagnostic services, device 
programming or reprogramming services, etc. 

The service gateway operator station 28, and the service provider stations 32 and 36 can 
be configured as separate computer systems of any suitable type for holding and 
supplying services in the form of software modules and/or data via the Internet on 
25 request. The service gateway operator stations and/or the service provider stations can 
be implemented by respective web sites provided by the service gateway operator and/or 
the service providers and/or hosted by a third party. Accordingly, it will be appreciated 
that the representation of the service gateway operator station 28 and the service provider 
stations 32 and 36 in Figure 1 is merely as a conceptual source of information which can, 
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in practice, be implemented using any technology. It will be appreciated that, although 
one service gateway operator 28 and two service providers 32 and 36 are shown, in 
practice there can be more than one service gateway operator 28 and there will typically 
be many service providers supporting stations such as the service provider stations 32 
5 and 36 illustrated in Figure 1 . 

The service gateway station 12 can be implemented as a stand-alone computer, for 
example a personal computer or another form of computer workstation, or a server 
computer. Alternatively, it may be implemented by any other piece of network enabled 
10 equipment, for exaiadple a unit typically described as a set-top box. 

Figure 2 is a schematic representation of such a set-top box 40. As shown in Figure 2, 
the set-top box 40 includes a display panel 42, input devices including key buttons 44 
and a pointing device 46, and an outlet 48 for a loud speaker. The set-top box of Figure 
15 2 can also incorporate a microphone, can be provided with stereo speakers, can be 
provided with an alternate form of display, and indeed can have a completely different 
format. Not shown in Figure 2, and typically located at the rear of the set-top box 40, are 
a number of appropriate connectors for enabling connection of the set-top box to the 
external and internal networks represented in Figure 1 . 

20 

Figure 3 is a schematic representation of an exemplary configuration of components of 
the set-top box 40 of Figure 2. Thus, as shown in Figure 3, a number of components are 
connected via a bus 50. A microprocessor or microcontroller 52 is connected to the bus 
50 and is able to access random access and/or read only memory 54 that is also 
25 connected to the bus 50. A media interface 56 enables the connection of a media drive 
58 to the bus 50, A remote interface 60 enables the connection of the bus 50 to the 
external network via the connection 14. First and second local interfaces 62 and 64 
enable the connection to the local networks 16 and 18. It will be appreciated that the 
illustration of two local interfaces 62 and 64 is by way of example only, and that there 
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may be only one local interface, or there may be more than two local interfaces. Each 
local interface is arranged to support one or more local network protocols. A user input 
device interface 66 enables the connection of the keys 44 and the pointing device 46 to 
the bus 50. A display interface 68 also enables the connection of the display 42 to the 
5 bus 50. An audio interface 70 enables the connection of the loud speaker 48 to the bus 
50 and optionally enables the connection of a microphone 72 to the bus 50. 

It will be appreciated that the configuration shown in Figure 3 is merely an example of a 
configuration of hardware components within a set-top box 40 as shown in Figure 2. It 
10 will also be appreciated that other configurations are possible, including the 

incorporation of many of the separate units shown in Figure 3 within a single large-scale 
integrated circuit. Other embodiments may have more than one internal bus 50 to enable 
different data rates to be supported efficiently between the various components of the 
set-top box. 

15 

It will also be appreciated that a configuration not dissimilar to that shown in Figure 3 
can form the basis of an embodiment of the service gateway implemented by means of a 
personal computer, or the like. In such a case the display interface 68 can support a full 
size computer display and the user input device interface 66 can support a conventional 
20 keyboard and mouse, or the like. 

Figure 4 illustrates a number of functional elements provided within the memory 54 of 
Figure 3 as used for controlling the microprocessor 52. The functional elements shown 
in Figure 4 are typically implemented by software modules using appropriate 
25 programming languages. In the present instance, the present example is based on a basic 
real time operating system 80. Supported on the real time operating system 80 is a 
virtual operation system environment, in this example a Java (TM) virtual machine 
environment 82. A service support framework 84 is configured on the Java virtual 
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machine environment 82. The service support framework 84 supports a variable number 
of services 86, which services are registered with the service support framework 84, 

Figure 5 illustrates, in more detail, a number of the software components of an 
5 embodiment of a service gateway 90 according to the invention. A service resolver 92 is 
responsive to requests from individual services 94. A number of such services 94 are 
provided to support the devices 26 in the local environment 20. A service negotiator 96 
is responsive to the service resolver 92 obtain information from a service provider or 
service gateway operator on request from the service resolver 92. A number of response 
10 engines 98 are operable to control the handling of data streams provided by a service 
provider or service gateway operator. The service resolver 92 refers to and maintains a 
local service table 100 that links service names 102 to pointers 104 to those services as 
supported locally. The pointers 1 04 point to the respective individual services 94 as held 
within the memory 54 of the service gateway. 

15 

It should be noted that each of the services 94, the service resolver 92, the service 
negotiator 96, and the response engines 98 are registered with the service support 
framework 84 as services 86 as represented in Figure 4. 

20 In a particular embodiment of the invention, the service support framework 84 is 

embodied using a "Java Embedded Server" (JES) product. The local services table 100 
is then embodied as the JES registry, that is a registry where all JES-enabled services are 
registered. The Java Embedded Server (TM) product is a small footprint Java (TM) 
technology-based server for networked devices. The service support framew^ork 84 is 

25 called a "ServiceSpace" (TM) and comprises application program interfaces (APIs) for 
life-cycle management of plug-n-play services and applications. The service support 
framework 84 provides installation, versioning, content management, monitoring, and 
service discovery functions. Individual services can include HTTP services, SNMP 
services, logging, thread management, remote administration, servlet support, etc. 
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Further details of Java Embedded Server (TM) products can be found at 
http://www.sun.coni/software/enibeddedserver/overview/index.htnil. 

An Embedded Server can provide services such as: 
5 a HyperTextTransfer (HTTP) service that allows client services to export their resources 
via the HTTP protocol; 

a Log/Remote Log Service that defines a system log-like interface for logging errors and 
events; 

a Date Service that provides a date (and time) service; 
10 a Connection Manager Service that enables services to interact with a network, including 
handling socket binding, accepting connections, and unbinding all bound services when 
stopped by the service support framework; 

a Thread Manager Service that provides thread management for the service support 
framework and its services; 

15 a Scheduler Service that allows client services to schedule events for points in the future; 
a Remote Method Invocation (RMI) Service that provides RMI support for bundles and 
maintains a single RMI registry throughout the service support framework; 
a Simple Network Management Protocol (SNMP) Service that acts as an agent between 
local and remote SNMP entities, such as browsers; 

20 a Console Service that provides remote administration via an applet, with the applet 
being exported via an HTTP or RMI service, depending on which protocol is chosen; 
an HTTP-based implementation of Remote API that provides the back end of a client- 
server administration capability and exposes the service support framework APIs via 
HTTP by registering an administration servlet with the HTTP service; and 

25 an RMI-based implementation of Remote API service that provides the back end of a 
client-server administration capability and exposes the service support framework APIs 
via the RMI protocol. 
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The service support framework 84 manages dependency relationships between bundles. 
For all practical purposes, a bundle is a file that can contain any amount of code or 
functionality as required. A bundle can be narrowly defined and only contain a limited 
number of files and functionality, or it can be broadly defined and contain much more. 
5 A dependency relationship exists when one piece, or chunk of Java code relies on 

another piece or chunk of Java code to operate properly. However, the defining detail of 
a dependency relationship is that the two chunks of code must be in different bundles. 
For example, the JES core HTTP service is dependent on the connection manager 
service, because without the connection manager is cannot make HTTP connections, 
10 Where both of these services are installed in the service support framework in different 
bundles, there is a dependency between them. However, if the HTTP service and the 
connection manager service were packaged together and installed as part of the same 
bundle, there would be no dependency relationship. 

From the above, it can be seen that the service support framework 84 of the environment 
shown in Figure 4 provides a mechanism for recognizing and monitoring dependency 
relationships across bundles, including recognizing dependencies, tracking 
dependencies, making bundles that need each other to be aware of the others' 
availability, facilitating interactions between dependent bundles, monitoring 
dependencies across life-cycle events and updating dependencies when they change. An 
embodiment of the present invention takes advantage of the functionality provided by 
such a service support framework 84. 

Referring once more to Figure 5, the service gateway 90 provides an embedded 
25 subsystem in a network environment to connect an external network to internal clients. 
The service gateway 90 thereby provides an interface between service providers and/or a 
service gateway operator and local devices held on the client's local system. The service 
gateway thus separates the topology of the overall environment into an external network 
envirormient and an internal network environment. As mentioned above, different types 
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of devices can support the service gateway, including a set-top box, a router, dedicated 
hardware, a power meter, a personal computer, etc. 

As indicated also above, an embodiment of the invention provides three different types 
5 of modules in the form of a service resolver 92, a service negotiator 96 and a response 
engine 98, wherein there may be multiple examples of the response engine 98, with each 
of those entities being implemented as a service registered with the service support 
framework 84, 

10 A brief exemplary summary of the operation of an embodiment of the service gateway 
90 of Figure 5 will now be described with reference to Figure 6. 

When one of the services 94, or another application operating in the local site supported 
by the service gateway requires another service to carry out a task, that service 94 or 
15 application calls the service resolver 92, As a parameter of the call, it is possible to 
specify a logical name of the service being requested. 

Figure 6A represents a request from a requestor service to the service resolver 92 for a 
service A. 

20 

The service resolver 92 then queries the registry 100 (where all the enabled services are 
registered) to see if the service name "A" is registered. 

If the requested service A is found, then the service is returned to the requestor. If, 
25 however, the requested service is not found, the service resolver 92 makes use of the 
service negotiator 96, The service negotiator 96 negotiates the requested service with 
the service provider by sending an HTTP GET with some additional information on the 
requested service. Figure 6B represents the sending of a query (HTTP GET) with the 
requested service name ''A". 
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The service negotiator 96 returns to the service resolver a service name and an input 
stream that is provided by the service provider. The input stream forms a payload for the 
response. Figure 6C represents the return of a response from the service provider with a 
5 proposed service Y that includes an encoded version of the requested service A A(ENC) 
as an input stream. Y is the name of the service needed to decode the encoded service A. 

The service name can be expHcitly provided using a dedicated HTTP header field. The 
header field can also identify the format of the input stream to be received. If available, 
10 the service resolver 92 retrieves the service specified in the response from the service 
negotiator 96. 

The service resolver 92 then employs a response engine 98 appropriate for the protocol 
of the received information to manage the transfer of the input stream to the identified 
15 service. 

This is an interactive process. That is to say, if the service having the name specified in 
the response from the service provider is not locally available in the service gateway 90, 
the service resolver 92 will once again make use of the service negotiator to obtain a 
20 further service for resolving this matter. 

For example, if it assumed that the service gateway does not have the service Y for 
decoding the encoded version of the service A, then a farther request can sent to the 
service provider specifying the service name Y as represented in Figure 6D. 

25 

The service provider can then respond by specifying a service X with the code for the 
service Y as an input stream as represented in Figure 6E. The service X can be the 
service name for a Zip function for unzipping a zipped up version of the code for the 
service Y. Let us assume that the unzip service is held by the service gateway. 
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The service gateway can then operate to use the service X (the unzip service) to unzip 
the code for the service Y. The service Y can then be used to decode the service A, 
whereby the service A can then be provided at the service gateway. 

5 

It can be seen from this example that an embodiment of the invention can provide a 
flexible and extensible approach to the provisioning of services at a local service 
gateway. It can also be seen from this specific example that an embodiment of the 
invention can provide for the secure communication of software and/or data from a 
10 service provider to a service gateway for secure provisioning of services at the service 
gateway. 

The individual jfunctions of the service resolver 92, the service negotiator 96 and the 
response engine 98 will now be explained in more detail below. 

15 

Service Resolver 92 

The service resolver 92 provides a central point of contact for service provisioning in the 
service gateway. The service resolver 92 is responsible for installing and activating 

20 bundles associated with a service description. If a service is not already registered with 
the service support framework 90 (i.e., its name is not held in the registry 100), then the 
service resolver 92 is responsible for organizing contact with the service provider or 
service gateway operator to provision an appropriate service bundle. In order to do this, 
the service resolver 92 makes use of the service negotiator 96, as described below, in 

25 order to obtain instructions from the remote service provider or service gateway 

operator. It then hands over received instructions to a response engine, as also described 
below, to process the provisioning instruction. Once an instruction is executed, the 
resolver queries the service support framework to check if the service is now available. 
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A summary of a method for providing the service resolver is set out in Table 1 below: 



TABLE 1 


Method Summary 


com.sun.servicespace.BundleC 


getServiceQava.net.URL url^ 


ontext 


com.sun.servicespace.ServiceDescription sd) 




Get the service associated to the given service 




description 



5 More detail of the method or the resolver service is set out in Table 2 as follows: 
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TABLE 2 



getService 





Get the service associated to the given service description. If the 
requested service is found, the caller can access the service by calling: 

servicespace,getService(BundleContext, ServiceDescription) 

Note that such a call creates a dynamic dependency between the caller and the service. 
That is why the method does not return a reference on the requested service. 
Parameters; url - An optional URL where to query if the service is not found locally. 



Returns: 

A BundleContext instance, or null if the service could not be found. 



Service Negotiator 96 

5 

The service negotiator 96 is responsible for communicating with an external service 
provider or service gateway operator. The service negotiator 96 is called by the service 
resolver 92 if the service resolver 92 needs to find services not currently registered with 
the service support framework 84. 



The service negotiator 96 can be called to invoke services at the service provider or 
service gateway operator. The service negotiator 96 sends a request to a server for the 
service provider or service gateway operator. When it receives a response it tries to 
identify a proper response engine from information in the response header in order to be 



sd - The service description of the service to be found. 



10 
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able to process the response. A response engine as described below is identified by a 
service description. 

The service negotiator 96 is operable to handle communication with the service provider, 
5 whereby services supported by the service gateway are not impacted by changes to the 
communication scheme used for communication with the service provider. 

The service negotiator 96 invokes a service provider using either a URL specified in a 
call to an HTML anchor or a predefined URL. 

10 

The service negotiator 96 sends a response to a service provider and identifies a response 
engine able to handle the response. It then returns an instruction to the service resolver. 

The service negotiator 96 expects a response engine to be specified by a specific HTTP 
15 header and can be configured using a specific instruction. By default, a header name is 
"engine". 

If no header is present, the service negotiator 96 uses a MIME type of the content that a 
service provider indicates should be used. For example, the mind types "text/plain" and 
20 "text/html" can be supported. 



A summary of the method providing a negotiator service is set out in Table 3 below: 
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TABLE 3 



Method Summary 


java.lang.String 


getServiceProvider ( ) 

Returns the service provider the negotiator is 
dealing with 


NegotiatorService.Instruction 


sendRequest (java.net.URL url, 
javaJang. String requestName, 
java.util.Properties requestParams) 
Query the service provider. 



More detail of the methods in the method summary are set out in Table 4 below: 
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TABLE 4 

SendRequest 

Public NegotiatorService. Instruction sendRequest (java.net.URL url, 

java.lang. String requestName, 
java.utiLProperties requestParams) 
throws java.io JOException 

Query the service provider. 

If the URL is not specified, the service will use the default one (returned by 
getServiceProvider. 
Parameters: 

url - A URL where to send the request. If not specified, the negotiator will use a 
predefined one, 

requestName - The name of the service to be invoked. 
requestParams - The parameters for invoking the service 
Returns: 

An Instruction instance 
GetService Provider 

public java.lang.String getServiceProvider ( ) 

Returns the service provider the negotiator is dealing with. 



Response Engine 98 

5 As indicated above, a response engine 98 is responsible for processing an input stream 
received by a service negotiator. The response engine for processing a response received 
from a service provider is selected by the service negotiator 96 using the header of the 
response, as described above. The selected response engine receives an input stream to 
process. The appropriate choice of response engine enables the service provider and the 
10 response engine concerned to agree on the structure of the input stream. 
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A summary of the method provided by a response engine is set out in Table 5 below. 




TABLE 5 


Method Summary 


java.iang.Object 


processResponse (java.net.URL url, 




java.io.InputStream resource) 




Handle an input stream received by a negotiator 




service. 



5 

More detail of the method is set out in Table 6 below: 

TABLE 6 



ProcessResponse 

Public java.iang.Object processResponse (java.net.URL url, 

java.ioTnputStream resource) 
throws com.sun.servicespace.BundleException, 
java.io.IOException 
Handle an input stream received by a negotiator service. 
Parameters: 

resource - the InputStream 



10 Figure 7 is a flow diagram illustrating the operation of the various services as described 
above. 

In this example, it is assumed that a service registered with the service support 
framework (hereinafter service requestor) requests a service A. Accordingly, in step SI, 
15 the service requestor issues a request for service A to the service resolver 92, In step S2, 
the service resolver 92 checks whether the service name is held in the registry 100. 
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In step S3, if the service name is held in the registry 100, the service resolver 92 is 
operable to return the pointer to that service to the service requestor 94, which is then 
operable to process call that service in step S4. 

5 

If, in step S2, it is determined that the service name is not held in the registry 100, then 
in step S5, the service resolver 92 issues a call to the service negotiator 96 to request that 
the service negotiator 96 obtains the service from an appropriate service provider, or the 
service gateway operator. Accordingly, in step S6, the service negotiator sends a call to 
10 an appropriate service provider or service gateway operator. The service negotiator is 
configured by the gateway operator. In addition, it is possible for a service requestor to 
query the service resolver with a specific URL, by passing the default configuration to 
the service negotiator. 

15 In step S7, the service provider or service gateway operator is operable to process the 
call from the negotiator service, and to return an appropriate response relating to the 
requested service. In step S8, the service negotiator 96 is operable to receive the 
response and to forward this to the service resolver 92. 

20 In step S9, the service resolver is operable to check whether a service name in the 

response provided from the service provider or service gateway operator via the service 
negotiator is held in the registry 100. 

If it is not held in the registry 100, then in step SIO, control passes back to step S5, 
25 where a further call is made to obtain a further service to resolve the outstanding issues. 
This loop can continue until it is determined in step S9 that the required service is 
registered in the service registry 100. 
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If the service name concerned is registered in the service registry 100 and no further 
information is required, then in step S 11, the pointer to the service is returned to the 
service requestor which, in step SI 2, then calls the service to process the result, 

5 Alternatively, if it is determined in step S9 that the service is in the registry and, 
additionally, it is necessary to obtain a download of an input stream from the service 
provider, the resolver service then calls in step S13 an appropriate response engine 98 to 
process the input stream. 

10 The identification of an appropriate response engine 98 is made by the service negotiator 
96 on the basis of the header of the response, if specified, and/or on the format of the 
response. Once the appropriate response engine is identified, the service negotiator 
builds an instruction for the service provider to execute. The instruction contains a 
logical name and the input stream to pass over to the identified response engine. 

15 

The response engine 98 selected is operable in step 814 to handle the received input 
stream, including, where appropriate, requesting that input stream from the service 
provider or service gateway operator. 

20 In this case, the service provider or service gateway operator is responsive to the 

response engine to return in step S 1 5 the input stream required. The response engine is 
operable in step S16 to process the received input stream and to return this to the service 
resolver 92 which forwards the appropriate input stream to the service requestor in step 
S17. 

25 

The service requestor is then operable in step S 1 8 to process the received information. 

There has been described, therefore, a service gateway that connects at least one local 
client to an external network. The service gateway is operable to hold at least one 
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service module for providing a corresponding service and to maintain a record 
identifying each service module held by the service gateway with an associated pointer 
to that service module. The service gateway includes a control mechanism providing a 
number of functions. The control mechanism is operable in response to a request for a 
5 service provided by a service module not present at the service gateway, to send a 
message to an external source for resolving the absence of a service module at the 
gateway in one or more iterations until a response from the external service identifies 
information including a service module held by the gateway that enables resolution of 
the absent service modules(s). The service gateway is thus arranged to provide an 
10 iterative, or recursive, process for repeatedly seeking a further service until the necessary 
software and/or data is available at the service gateway to satisfy the original service 
request. 

The resolver, the negotiator and the response engines are configured as software services 
15 registered with the service gateway. These services can be provided as computer 

programs on a carrier medium. The carrier medium can be a storage medium (such as an 
optical, a magneto-optical, a magnetic or a solid state storage medium configured as a 
disk, tape or solid state device, etc), or a transmission medium (such as a telephonic, 
wireless, copper, optical or other wired medium, etc), or a mixture thereof, as 
20 appropriate. 

Although particular embodiments of the invention have been described, it will be 
appreciated that many modifications/additions and/or substitutions may be made within 
the scope of the invention. 



